Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development

Using the getManagerHandle function

The handles of the basic managers are available as global variables defined in src/adm2/globals.i. New managers and other useful handles should not be defined in this way, to avoid the unnecessary proliferation of global variables and the need to recompile every procedure in the framework, and also in your application, when one is added.

For all managers, the Configuration File Manager supports a function that returns the handle based on the manager’s name, or more precisely, the Manager Type Code from the Manage Type maintenance utility under the Session menu. If you look at all the existing managers, you can see the Manager Type Codes for them, and also note the value of the Static Handle field.

The first thing to note is that the Configuration File Manager itself is not on the list. This is because it’s always the first thing started and always starts everything else, so only other managers are listed in the configuration information for a session.

Look at the Static Handle field in Figure 6–6 and note that all the basic managers, except for the Connection Manager, have a two- or three-letter symbol for the handle name. This indicates that there is a static handle for the manager. The Connection Manager has a Static Handle code of NON, short for none, meaning no static handle available.

Figure 6–6: Static Handle field of the Manager Type Control wIndow

If you edit the Manager Type for one of the other managers, a Static Handle name such as gshSessionManager, is shown. Figure 6–7 shows that there is no static handle for the Connection Manager.

Figure 6–7: Manager Type Maintenance - Connection Manager

This is because the Connection Manager was created after the other basic Progress Dynamics managers, and observes the policy of not creating new handles for new managers. To obtain its handle, use the getManagerHandle call, as shown:

hManager = DYNAMIC-FUNCTION(‘getManagerHandle’, pcManagerTypeCode).

You can reference the API calls in the Configuration File Manager as if they were in your application procedure, but because no function prototypes for the functions are included, you must use the DYNAMIC-FUNCTION syntax to avoid a compile-time error message that the compiler does not recognize the function name.

Here is an example of using this call:

/* testManagerHandle.p -- test the getManagerHandle function. */ DEFINE VARIABLE hConn AS HANDLE NO-UNDO. DEFINE VARIABLE hSess AS HANDLE NO-UNDO. hConn = DYNAMIC-FUNCTION('getManagerHandle', 'ConnectionManager'). hSess = DYNAMIC-FUNCTION('getManagerHandle', 'SessionManager'). MESSAGE "The Connection Manager is running " hConn:FILE-NAME SKIP "and the Session Manager is running" hSess:FILE-NAME.

Note that because you do not use the global handle variables in globals.i, you do not need to reference the include file unless your code elsewhere references one of the other manager handles directly.

Run this code to see the Message window, as shown: